RHIDP-5483: Update Authorization Preface #1052
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
@themr0c any idea why the Preview is failing? |
| @@ -1,26 +1,18 @@ | |||
| [id='configuring-authorization-in-rhdh'] | |||
| = Configuring authorization in {product} | |||
|
|
|||
| In link:{authorization-book-url}[{authentication-book-title}], you learnt how to authenticate users to {product}. | |||
| {product-short} knowns who the users are. | |||
| Administrators can authorize users to perform actions and define what users can do in {product-short}. | |||
There was a problem hiding this comment.
For clarity, consider not using "Administrators" alone. We have different admin roles: "platform engineer aka. OCP administrator" / "RHDH administrator" / "RBAC administrator".
The distinction is also missing in the previous content.
It would be nice if the introduction would clarify the roles:
-
(A) Platform engineer / OpenShift user with developer privileges. Roles in authorization:
- Enable the RBAC feature
- Define RBAC administrators
- When using policy files: define authorizations
-
(B) RBAC policy administrator = RHDH user with manager priveleges on RBAC policies. Roles in authorization:
- When using the RBAC REST API: define authorizations.
-
(C) RHDH administrator => this is a confusing role, with 2 indentities:
- First identity: (A) OpenShift user with developer privileges that manages the RHDH instance on OpenShift; authenticated in Openshift. Roles in authorization: see (A).
- Second identity: (D) RHDH user with administrative privileges; authenticated in RHDH authentication provider, which is external, and might be different from the OpenShift authentication provider. Roles in authorization: see (B).
There was a problem hiding this comment.
@themr0c so which role / permission is required to authorize users to perform actions and define what users can do in RHDH?
If you're saying there are conditions and various admins can do this in various ways, then I agree that we should probably describe those roles / perms in detail, but that doesn't necessarily mean that the statement with the general Administrators term is not true and valid.
I think we definitely need some further exploration and enhancement there, but this PR is intended to be a copyedit to comply with Minimalism and grammar standards rather than a deep content edit.
There was a problem hiding this comment.
I also think it might be ok to speak more generally in the assembly, as long as our content in technically accurate, and then outline each of these roles / responsibilities in more detail in modules (or a reference module) within the assembly. Think about how a user / particular persona would navigate the docs to find out who, what, and how to authorize users.
IMPORTANT: Do Not Merge - To be merged by Docs Team Only
Version(s):
1.4, 1.5
Issue:
RHIDP-5483
Preview:
TBD